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Abstract. Service-oriented Mobile Social Network in Proximity (MSNP) lets par¬ 
ticipants establish new social interactions with strangers in public proximity us¬ 
ing heterogeneous platforms and devices. Such characteristic faces challenges in 
discovery latency and trustworthiness. In a public service-oriented MSNP environ¬ 
ment, which consists of a large number of participants, a content requester who 
searches for a particular service provided by other MSNP participants will need to 
retrieve and process a large number of Service Description Metadata (SDM) hies, 
associated semantic metadata hies and identifying the trustworthiness of the con¬ 
tent providers. Performing such tasks on a resource constraint mobile device can be 
time consuming, and the overall discovery performance will be affected and will re¬ 
sult in high latency. This paper analyses the service discovery models of MSNP and 
presents corresponding solutions to improve the service discovery performance of 
MSNP. We hrstly present and analyse the basic service discovery models of service- 
oriented MSNP. To follow up, we apply a context-aware user preference predic¬ 
tion scheme to enhance the speed of the semantic service discovery process. Later, 
we address the trustworthiness issue in MSNP and propose a scheme to reduce the 
latency of the trustworthy service discovery for MSNP. The proposed scheme has 
been tested and evaluated on MSNP application prototype operating on real mobile 
devices and MSNP simulation environments. 

Keywords. Web service, service-oriented architecture, service discovery, mobile 
social network, workhow, trust, context-awareness 


1. Introduction 

1.1. Preamble 

Accessing Social Network Services (SNS) such as FaceboolQ Twittei^Jor Googledj^Jhas 
become a common daily activity for Internet users. The marketing report jT| shows that 
on average, a Facebook user accesses Facebook’s services for over 7 hours per month, 
and with around 80% usage traffic derived from mobile applications. Recent smart mo- 
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bile devices, such as smartphones, tablets, handheld media players are capable of letting 
users produce various digital content, and share/upload the content to many SNS directly 
via wireless network connections. This has increased the number of people using mobile 
SNS applications. 

Although the marketing report has shown that mobile SNS applications have suc¬ 
cessfully become the most popular applications for mobile users, mobile users have been 
restricted in the virtual communities of online SNS and are not aware of the social op¬ 
portunities available to them. While mobile users spend most of their time accessing 
the online SNS, they have missed many opportunities to interact with others for new 
friendships, business opportunities, or information sharing Consequently, applica¬ 
tions such as those by MobiSoC (2), MobiClique [3], MoSoSo 0, Uttering [5] and 
Spiderweb [6| have been proposed to enable a new breed of Mobile Social Network 
(MSN) functions, which can assist mobile users to interact with proximal people and 
perform various social activities such as searching for new friends who have common 
interests, exchanging content of common interests and establishing conversations. In this 
paper, such a proximal-based MSN environment is termed a Mobile Social Network in 
Proximity (MSNP) 0E9- 

An MSNP should not be seen as a replacement of existing SNS but as its comple¬ 
ment (3J. MSNP leverages online SNS with a proximal mobile wireless network con¬ 
nection by providing location-based social networking opportunities. It can be applied 
in various social scenarios. For example, with the assistance of MSNP applications, an 
attendee in a highly populated conference can easily find someone who has common in¬ 
terests based on information derived from public profiles and their public information on 
online SNS. Another example: visitors who attend a big exhibition such as ComikeQin 
Japan or Comic-Con in US^and Australia^] may be at a loss as to where they can find 
something they are interested in. With MSNP applications, they can rapidly discover the 
information about any point-of-interest shared by other MSNP application users based 
on their preferences in the same exhibition. MSNP also provides opportunities for ac¬ 
tive MSNP application users to bring more visitors to their online SNS spaces. For ex¬ 
ample, Twitter users can actively advertise content to MSNP application users who are 
potentially interested in the content, in order to bring more followers to their Twitter. 

Although several software frameworks have been proposed to enable MSNP, most 
of these works are tightly coupled systems. In the past decade, service-oriented archi¬ 
tecture (SOA) has become the mainstay of networked application development. Within 
SOA developments, the standardised Web service technologie^] that provide platform 
independent common intercommunication interfaces have been broadly applied in var¬ 
ious networked distributed computing areas to enhance the interoperability of differ¬ 
ent machines with heterogeneous software platforms. Web service has also been ap¬ 
plied to numerous mobile applications either by utilising mobile applications as Web ser¬ 
vice clients fTT|{T4| , or embedding HTTP Web servers to provide Mobile Web Service 
(MWS) directly from mobile devices fl5}|T8] l. Utilising Web services can enable loose 
coupling and platform independent features for MSNP environments. 
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Our research focuses on realising a loosely coupled, service-oriented MSNP envi¬ 
ronment based on Web service standard technologies. Service-oriented MSNP provides 
an open standard environment. With open standards, mobile application developers can 
easily implement compatible applications for mobile users to participate in MSNP with¬ 
out being bound to a particular device or software platform. 

7.2. Research Motivations 

Imagine an MSNP environment with a verity of mobile device users. Each user intends 
to use their MSNP application to interact with one another. However, due to each MSNP 
application being implemented in different technologies, the opportunity of discovery 
and interaction between mobile users is much less. For example, a user who is using an 
MSNP application based on JXTA (Juxtapose^] will be unable to communicate with 
a user who is using the Universal Plug and Play (UPnP)-basecf^l MSNP application, 
because the way they perform discovery is different. Moreover, when the environment 
grows, the number of operation types and content types increases. In order to fulfil the 
need, semantic annotation may be applied to describe the operations provided by each 
participating device. However, due to the heterogeneity issue, the semantic discovery 
mechanism is difficult to be implemented. Conversely, if the entire system is Web service 
compliant, the overall interoperability can be highly improved. 

The benefit of applying Web service standards in MSNP is explicit. However, en¬ 
abling decentralised Web service-oriented MSNP faces a number of challenges: 

• Service Discovery Latency—In service-oriented MSNP, each user’s mobile de¬ 
vice is a Web service client and also a Web service provider fl6| . Since Web 
service has been applied as the common communication interface, and in most 
cases, MSNP participants do not have pre-knowledge about other peers in or¬ 
der to support the service discovery process, each MSNP peer can use semantic 
Web standards, such as Web Services Description Language (WSDL), Extensible 
Markup Language (XML), Semantic Annotation for WSDL and XML Schema 
(SAWSDLand Web Ontology Language (OWLf^l to describe its services. 
While performing service discovery, an MSNP peer has to retrieve and process 
the other participants’ service description metadata at runtime to enable dynamic 
Web service binding. Moreover, an MSNP peer is required to perform trust con¬ 
trol processes on mobile devices in the mobile peer-to-peer (MP2P) network en¬ 
vironment. Such a discovery process can cause high latency when the environ¬ 
ment consists of large number of mobile Web service providers. Moreover, the 
dynamic nature of MP2P requires the service discovery process to be fast in order 
to enable further interaction processes, because MSNP peers are extremely mo¬ 
bile. Each can move out from the current Wi-Fi network and join another, or can 
switch between 3G/4G mobile Internet. 

• Trust—Suppose a content requester discovers a Web service from a previous 
unknown content provider who can provide content of interest to the requester. 
Should the requester use the service to retrieve the content? In a basic process, 
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the decision can be made by the human manually. However, if a more advanced 
autonomous service discovery operation is required, the task becomes critical. 
Imagine an MSNP participant intends to mashup a particular content from all 
content providers who provide the corresponding services. The process becomes 
inefficient if it requires the human user to manually select which providers’ ser¬ 
vices they want to use. Hence, an autonomous decision making mechanism is 
more efficient, but trust is a major concern. Fundamentally, supporting trust in a 
Web service environment such as applying WS-Trus{^] requires a global entity 
to manage the trust-related data. However, because service discovery in MSNP is 
based on MP2P topology, it is impossible to establish a global central manage¬ 
ment party for supporting trustworthiness p9| . Hence, each MSNP participant 
has to manage the trust by itself. In a common SNS such as Facebook, a user 
can define different levels of content accessibility according to different social 
groups. A similar approach can be applied in a MSN solution f20| . However, for 
a new MSNP participant, who does not have many contacts, it is hard to define 
such access control. 

This paper presents an extension of our previous works f7||9||2H and provides the 
details in service discovery of MSNP. In this paper, we analyse the service discov¬ 
ery models of MSNP and presents corresponding solutions to improve the service dis¬ 
covery performance of MSNP. The two major challenges: Service Discovery Latency 
and Trust are analysed. Their corresponding solutions: a context-aware user preference- 
associated proactive service discovery scheme and a lightweight trustworthy service dis¬ 
covery scheme are proposed and evaluated. 

This paper is organised as follow: Section 2 proivdes a literature review of related 
works. Section 3 provides an overview of service-oriented MSNP architecture. Section 
4 presents and analyses the basic service discovery models of service-oriented MSNP. In 
Section 5, we apply a context-aware user preference prediction scheme to enhance the 
semantic service discovery process. In Section 6, we address the trustworthiness issue in 
MSNP and propose a scheme to reduce the latency of the trustworthy service discovery 
for MSNP. Section 7 presents the evaluation of the proposed schemes. Section 8 sum¬ 
marises our work and provides the future research directions in this research domain. 


2. Background 

An ideal MSNP framework should support the following capabilities: 

• Decentralised , which can avoid single point of failure issues. 

• Autonomous discovery , to support a mechanism to improve the discovery result. 

• Trust, to support trustworthiness to help users interact with people who are not in 
their contact list. 

• Loose coupling. To enhance the interoperability of a heterogeneous platform. 

• Latency reduction , to provide a proper strategy to reduce the latency of the 
message-driven discovery, because a loosely coupled MSNP system faces latency 
challenges. 
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2.1. Related Frameworks 


Existing related frameworks are still in their early stages. None of the frameworks de¬ 
scribed below supports all the above ideals of MSNP. 

A purely centralised framework such as MobiSoC (2j and MobilisGroups (22) po¬ 
tentially harbours the risk of single-point-of-failure. Some centralised solutions such as 
Smart Campus Project (23) and SPN (24) support minor decentralised communication 
capabilities by utilising Bluetooth technology when the central server is not available. 
However, such a solution is insufficient, because by simply utilising Bluetooth-based 
discovery, it can result in high latency especially when the environment grows. 

Most existing works also lack support for heterogeneous platform interoperability. 
They were proposed in the form of stand-alone technology. Within these frameworks, 
some have applied standard service-oriented technologies. MobiSoC is a Web service- 
based framework that applied SOAP communication. MobilisGroups has utilised IETF 
XMPP (25) , which is a popular centralised standard communication protocol. SocioNet 
is also a Web service-based framework. Yarta has utilised standard protocol—Service 
Location Protocol (SLPj^] —for proximal mobile P2P discovery. 

Within these related frameworks, Yarta is the closest framework to achieve the basic 
capabilities described previously. It is capable of avoiding a single point of failure, and it 
supports heterogeneous platform interoperability and autonomous discovery. However, 
Yarta has not provided a strategy to reduce latency caused by applying standard semantic 
discovery technology in a MP2P network. The evaluation result of Yarta’s prototype has 
indicated that this is an issue. Further, Yarta has no support for resource-awareness, in 
which the discovery and interaction scheme should adapt to the resource changes and 
environmental factors. 

Overall, existing works did not address trustworthiness, which is an important aspect 
of MSNP because MSNP allows users to interact with new people who are not in their 
existing contact list. Without a proper strategy for trust, people will hesitate to use MSNP. 
Further, applying trust in MSNP can also cause additional latency in the bootstrap and 
discovery phase because MSNP is based on MP2P topology in which the involved data 
for performing trust control is distributed (e.g., stored in each MSNP participants’ back¬ 
end cloud storage) and require the mobile application to retrieve them at runtime via the 
unstable mobile Internet. Hence, reducing latency for discovery phase becomes a priority 
challenge which needs to be resolved in MSNP. In the next section, we review a number 
of trustworthy service discovery solutions designed for MP2P environments. 

2.2. Trustworthiness in Mobile Peer-to-Peer Environments 

A number of works have been proposed to support trustworthiness in MP2P environ¬ 
ments. While works proposed by Li et al. (26) and Rathnayake et al. (27) were focus¬ 
ing on how to improve the reliability of trust models by utilising the computation of a 
large number of trust-related data, resulting in insufficient processing speed in MP2P 
network (28) , some authors (29]-f3T) have proposed lightweight trustworthy service/peer 
discovery schemes for MP2P environments. 

Reducing data transaction is a common strategy to improve the processing speed of 
trust in MP2P. Wu et al. (29) have proposed a group-based reputation scheme. Their de- 
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sign is based on super peer MP2P network, in which a super-peer (which is described as 
Power peer in their work) manages the reputation rating data of a group of mobile peers 
with similar movement speed. However, in a public environment such as MSNP, users 
may not be willing to let their devices act as super-peers because the high frequency of 
data transaction through their mobile devices can consume too much hardware resources 
(i.e. CPU, RAM, battery life, etc.). 

M-Trust (30]] reduces reputation data transaction by selecting recommenders based 
on the confidence of the candidate recommenders. A disadvantage of M-Trust is that 
the system will directly remove a trustworthy peer’s recommendation (reputation rating) 
when the peer is disconnected from the current network (either due to network switching 
or due to the time to live of its recommendation expiring). It would be ideal to provide 
a strategy to let M-Trust retrieve updates from recommenders in a different network, but 
this has not been addressed. 

Similar to the fundamental strategy of M-Trust, TEMPR (3l| also improves the 
trust processing speed by utilising the selective recommender approach. Distinguished 
from M-Trust, the TEMPR scheme computes direct peers’ (candidate recommenders 
who can directly interact with the requester) trustworthiness based on two scores: (1) 
the direct peers’ trustworthy rating from other unknown peers; and (2) the direct peers’ 
untrustworthy rating from other unknown peers. 

Our work in trustworthy service discovery can be seen as an extension of TEMPR, 
designed specifically for service-oriented MSNP. The major difference is that we do not 
assume strangers’ application will always forward messages to assist other participants 
for the trust processes. Hence, a requester who intends to identify a provider’s trustwor¬ 
thiness has to obtain the reputation rating data by either directly retrieving the reputation 
data from the other MSNP participants or by retrieving the data from the other MSNP 
participants’ cloud storages. 


3. Service-Oriented MSNP Architecture Overview 

MSNP represents an environment in which mobile users utilise their mobile devices to 
perform social activities with each other in proximal distance. The fundamental aim of 
MSNP is to enable communication in a fairly close range so that the participants can po¬ 
tentially meet each other. Figure 1 illustrates an MSNP environment. In order to improve 
the interoperability, Web service has been utilised as the common communication inter¬ 
face. In an MSNP environment, each mobile device is a mobile Web service consumer 
and also a provider (T6) . When two peers join the same wireless network, they utilise 
standard communication technologies such as DPWS (32) or Zeroconf (33} to exchange 
their Service Description Metadata (SDM). For peers who do not have Mobile IPv6| 17 | 
we expect each to have its own back-end cloud storage to synchronise its IP address as a 
small text file in its cloud storage (or alternatively utilising public Domain Name System 
[DNS] servers if available). The Uniform Resource Locator (URL) of the text file is de¬ 
scribed in a peer’s SDM. Hence, when the peer (e.g., Figure 1, P2 or P4) moves out from 
the current network, the other peers (e.g., Figure 1, PI and P3) in their previous network 
can still interact with P2 or P4 via mobile Internet. 
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Figure 1 . Service-Oriented MSNP Architecture. 

Since PI and P3 have previously exchanged their SDM with P2 and P4, they have 
cached the SDM of P2 and P4 in either their local memory or synchronised it to their 
cloud storages. When PI and P3 receive requests from other peers in the same network 
that are performing service discovery, PI and P3 can also provide P2 and P4’s SDM to 
these requesting peers. Instead of having the SDM directly sent to the peers by PI and P3, 
PI and P3 can synchronise the cached SDM to their cloud storages, and simply provide 
the URL link to the requesting peers. 

A similar concept can be applied to content sharing and mashup, say for example, PI 
intends to mashup the content provided by P2 and P3. When PI invokes P2 and P3 for the 
content, P2 and P3 will simply reply with the corresponding metadata documents, which 
contain the description about where the content can be retrieved from in the Internet. For 
example, P2 has uploaded the content to a SNS as public accessible content. Hence, P2’s 
response metadata will contain the URL link of the uploaded content. 

Taking into account that mobile devices usually have limited processing power, it 
is reasonable for an MSNP peer to delegate some of its processes to its backend Cloud 
Utility Service (CloudUtil). In Figure 1, for example, PI utilises its backend CloudUtil 
for semantic service discovery. Further, CloudUtil can also be used to directly access 
the content uploaded by other MSNP peers in SNS to discover useful content for Pi’s 
mashup (if the content has been described in Rich Site Summary [RSS J^Jfeed format). 

A content provider in MSNP can also actively push recommendations to other par¬ 
ticipants based on the participants’ service preferences. Due to privacy concerns, MSNP 
peers may prefer not to share their private information. However, when a list of avail¬ 
able services (described semantically) is provided to the participants, the participants can 
simply reply which service type they are interested in. 
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4. Service Discovery in Service-Oriented MSNP 


This section presents and analyses the basic service discovery models of service-oriented 
MSNP. Before we proceed with our discussion, we define and reiterate the terminologies 
in a service-oriented MSNP: 

• A device represents a mobile device such as a smart phone, a handheld media 
player or a small tablet computer. A device can be operated by any operating sys¬ 
tem and is capable of participating in mobile P2P network using software appli¬ 
cations. 

• An agent represents an MWS-enabled software agent. The term—agent is derived 
from the software agent described in W3C Web Service Architecture document 
(34| , in which an agent performs Web service activities for its human user. In 
MSNP, an agent can perform functions for both MWS client and server. 

• A user is a human user who holds a mobile device that is embedded with mobile 
Web service (MWS)-enabled software agent. 

• An MSNP participant represents an entity which participates in an MSNP envi¬ 
ronment. Each MSNP participant consists of: a device , an agent , and a user. 

In MSNP, each agent would have pre-downloaded a fair number of public common 
ontologies that have been published on cloud resources (e.g., Swoogl^] or fusioiQ- 
A public common ontology describes numerous common service types and data types se¬ 
mantically. Each Semantic Annotations for WSDL and XML Schema (SAWSDL) (35)- 
compliant agent describes its services using semantic annotations that map to the corre¬ 
sponding ontology types. Benefiting from the public common ontologies and semantic 
annotation, an MSNP service requester’s agent can identify whether a service matches 
to the functionality it needs from the service provider’s WSDL and related documents 
(e.g., XML Schema). In the following subsections, we discuss service discovery models 
in MSNP. 

4.1. Pull-based Service Discovery 

Pull-based service discovery in service-oriented MSNP represents the most basic service 
discovery mechanism that is supported by the existing mobile P2P protocols (e.g., UPnP, 
Bonjour, DPWS, etc.) without making a significant assumption, such as expecting the 
requester agent to provide MWS to let other agents advertise SDM to it. 

Ligure 2 illustrates the process flow of the pull-based service discovery model de¬ 
scribed in Business Process Modelling Notation (BPMNpj The discovery process con¬ 
sists of five subprocesses: 

• Main Process. When a user joins an MSNP environment, he/she manually de¬ 
fines his/her need (task 1) and then requests his/her agent (denoted by agent rqt to 
discovery the corresponding service provided by other MSNP participants’ agents 
(task 2). The agent rqt launches the SDM retrieval subprocess and keeps the main 
process thread on stand by waiting for the result from the Trust Management sub- 
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Figure 2. Pull-based service discovery in MSNP 

process (task 19). When a trusted provider information is passed to the main pro¬ 
cess, agent rqt will invoke the corresponding service from the provider agent to 
retrieve the result (task 20). 

• SDM Retrieval. The SDM Retrieval subprocess is set to a finite timestamp (mark 
4). When time is up, this subprocess will be terminated. The main activity of 
this subprocess is to retrieve SDM from each MSNP participant’s agent in the 
requester’s current environment (task 5, 6). After retrieving and processing the 
SDM, agent rqt may find out that the provider agent is also providing a service 
which returns a list of other agents' SDMs which were fetched when the provider 
agent performed discovery previously when it joined the current environment. If 
such a cached SDM service is available, agent rqt will launch the Cached SDM 
Retrieval subprocess. 

• Cached SDM Retrieval subprocess retrieves one or more cached SDMs from 
the provider (task 13). The cached SDMs can either be retrieved from its provider 
agent directly or be retrieved from the provider’s cloud storage depending on 
the provider’s preference. The retrieved SDM is also passed to the Matchmaking 
subprocess (task 14). 

• Matchmaking. The retrieved SDM and its associated documents will be pro¬ 
cessed by the Matchmaking subprocess. The Matchmaking subprocess uses se¬ 
mantic reasoning algorithm and XML document parsing technologies to identify 
whether the provider can provide a corresponding service to fulfil the request or 
not (task 10). If the provider can provide the corresponding service, agent rqt will 
perform Trust Management (task 12). 

• Trust Management subprocess identifies whether the provider’s service is trust¬ 
worthy or not (task 16). If the provider’s service is trustworthy, agent rqt will per¬ 
form the service invocation to retrieve result from the provider (task 18). 

A drawback of this simple model is the latency issue. Because SDMs are described 
in XML format, resource-constraint mobile devices are usually unable to process a large 
number of XML documents effectively. 













































































4.2. Push-based Service Discovery 


Push-based service discovery approach involves a requester agent (agent rqt ) utilising 
passive mechanism to receive SDMs advertised by the other active MSNP participants’ 
agents. Figure 3 illustrates the process flow of push-based service discovery approach. 



Figure 3. Push-based service discovery in MSNP 

The behaviour of the main components in this approach is described below: 

• Main Process in push-based approach differentiates from the pull-based ap¬ 
proach in that agent rqt does not actively invoke the other participants’ agents to 
retrieve their SDM. Instead, agent rqt launches an MWS provider (task 2) to pas¬ 
sively receive SDM advertised by the other agents. 

• Mobile Web Service subprocess permits the requester to be passive. In this sub¬ 
process, agent rqt provides MWS to let other participants’ agent retrieve agent rq f s 
SDM (task 8). Based on agent rq fs SDM, other agents directly push their SDM 
to agent rqt . When agent rqt receives an SDM, it performs the matchmaking task to 
identify whether the SDM’s provider can provide the required service type or not 
(task 9). If the SDM’s provider can provide the required service type, agent rqt will 
perform the Trust Management subprocess to identify the provider’s trustworthi¬ 
ness (task 10). 

• Trust Management subprocess is the same as the Trust Management process 
described in the previous pull-based model. 

4.3. User Preference Associated Push-based Service Discovery 


In addition to the two basic service discovery approaches described in the previous sec¬ 
tions, we propose a new service discovery approach for MSNP—the user preference as¬ 
sociated push-based service discovery (PrefPush). The relative works of PrefPush have 
been previously published in (8 9|[2l|. PrefPush in MSNP relies on participants’ agents 
actively advertising their SDM to one another. A requester participant’s agent— agent rqt 



































































will perform the following three subprocesses to enable PrefPush. Figure 4 describes the 
process flow of the PrefPush- based service discovery model in BPMN. 



Figure 4. PrefPush -based service discovery in MSNP 


• Main Process is slightly different from the pull-based model. In the PrefPush 
approach, when a user joins the environment, agent rqt can autonomously identify 
its user’s preferred service in the current environment based on the user’s past 
request records and the current environmental context information (task 1). The 
details of the approach to enable the autonomous identification of the user’s pre¬ 
ferred service will be described in the next section. Alternatively, user can man¬ 
ually define his/her preferred service type prior or on demand at runtime. Once 
the preferred service type is identified, agent rqt launches its Mobile Web Service 
(MWS) server-side mechanism to let other participant’s agents actively interact 
with it (task 2). Afterwards, agent rqt puts the main process on stand by waiting 
for the result from the Trust Management subprocess (task 14). When a trusted 
provider information is returned from the Trust Management subprocess, agent rqt 
will invoke the trusted provider’s service to retrieve the result. 

• Mobile Web Service subprocess enables the requester to be passive. In this 
subprocess, agent rqt provides MWS to let other participants’ agents retrieve 
agent rq fs SDM (task 9). Based on the agent rq f s SDM, other participants’ agents 
can also request agent rqt for its user preferred service type (mark 7). The other 
participants’ agents who retrieved agent rq f s user preferred service type informa¬ 
tion, can determine whether their services can fulfil the need or not. If they can, 
they can post their SDM to agent rqt as advertisement. Note that, at this stage, we 
do not expect the other participants’ agent to directly post the content correspond¬ 
ing to the agent rq f s user preferred service type, because agent rqt does not know 
whether the provider is trustworthy or not. Hence, agent rqt expects a SDM adver¬ 
tisement rather then the corresponding content. Once agent rqt receives a SDM, it 
performs the Trust Management subprocess to identify the trustworthiness of the 
provider (task 10). 



































































• Trust Management subprocess is the same as the Trust Management process 
described in the previous pull-based model. 

The major difference between PrefPush and the previous two approaches (Pull and 
Push) is that in the PrefPush- based model, agent rqt does not need to perform any SDM 
retrieval process or perform semantic matchmaking process. Since the matchmaking pro¬ 
cess is done by other participants’ agents , the overall discovery makespan of PrefPush 
can be much lower than the other two approaches. 

However, the drawback of PrefPush is that it assumes other participants’ agents re¬ 
main active and will advertise their SDM to the others. Since such an assumption cannot 
be guaranteed, it is more feasible to perform both pull-based and PrefPush- based model 
at the same time for the service discovery. 

4.4. Hybrid-based Service Discovery 

Hybrid-based service discovery model in MSNP combines both pull and PrefPush- based 
service discovery models. Figure 5 illustrates a hybrid-based service discovery model. 
The service discovery process consists of three main parallel tasks: pull-based service 
discovery, PrefPush- based service discovery, and the trust management. 



Figure 5. Hybrid-based service discovery in MSNP 


When an MSNP user enters an MSNP-enabled environment, he can either manu¬ 
ally launch the application to search for his/her preferred service provider, or his/her 
agent can automatically triggers service discovery mechanism at background based on 
the user’s preference computed from the scheme described in Section 5. The agent will 
use a client-side MWS mechanism to search service providers and also launch an MWS 
server to allow other participants’ agents to actively advertise their SDM to it. 

The pull-based service discovery task and PrefPush- based service discovery task 
will pass SDMs retrieved from other service provider agents to the trust management 
task. If the provider is trustworthy, the agent will interact with the provider to retrieve 
the result/content as described in the previous two models. 


5. Context-Aware Proactive Service Discovery in MSNP 

Dey [ [36) defined context as: ‘ any information that can be used to characterise the sit¬ 
uation of an entity. An entity is a person, place, or object that is considered relevant to 
the interaction between a user and an application, including the user and applications 



















themselves.’ In the following paragraphs, we use Dey’s definition as the basis to describe 
context in this paper. 

Push-based service discovery in MSNP can be greatly improved by applying a 
proactive autonomous discovery mechanism. As Figure 3 shows, in the first task in the 
Main Process, if it relies on user manually entering the preferred service type, after the 
service type is entered, the user has to wait until the result returns. However, if the agent 
can predict the user preferred service type, it can support the PrefPush- based service dis¬ 
covery approach in which the agent can autonomously start the discovery process when 
the user enters the MSNP environment. By doing so, when the user starts using the appli¬ 
cation, the agent has already discovered and identified a list of trusted services provided 
by the others. Moreover, some results may have already been pre-fetched by the agent if 
the user has granted the agent to do so. 

In this section, we present our proposed context-aware proactive service discovery 
scheme for MSNP. The proposed scheme enables the agent to perform SDM prefetching 
and content prefetching to reduce service discovery latency. 

Before the details of the proposed scheme are discussed, we provide the background 
of the proposed scheme. 

5.1. Background of Proactive Service Discovery 

The fundamental part of the user preference associated push-based service discovery 
approach proposed is based on the autonomous data prefetching mechanism. In general, 
the prefetching mechanism consists of the elements described in the following sections. 


5.1.1. Prediction 


The prediction mechanism aims to predict a user’s request based on various factors. Fac¬ 
tors in a prefetching approach for Web browsing f37f[39) include user’s browsing history, 
interests, navigation behaviour, and the popularity of the available contents/resources. 
By analysing these factors and comparing them with presently available contents, the 
probability of user’s interest in a content can be computed. 

In mobile and pervasive computing environments, more factors need to be consid¬ 
ered 1 40-45]]. These are user’s current location, moving direction, hardware resources, 
network bandwidth, and many others. Based on these factors, corresponding policies or 
rules can be designed and applied to a decision-making scheme to predict and anticipate 
a mobile user’s future request more accurately. 

In Web-based systems, Jiang and Kleinrock p7| have introduced a prediction mod¬ 
ule to track user’s access history continuously. Based on the historical records, the sys¬ 
tem can compute the probability of user’s browsing actions, and determine what con¬ 
tent needs to be prefetched. An extended approach proposed by Tuah et al. (38| applied 
compound access graph to perform prediction based on the most recent browsing histo¬ 
ries and the relationships between web pages. A mobile environment based prefetching 
scheme proposed by Burklen et al. (39]] has considered the location factor. The predic¬ 
tion result was calculated based on the user’s searching histories in specific locations. 
These techniques were proposed for Web systems and their prediction decision modules 
only considered static factors. They did not consider dynamic factors such as the user’s 
preference in different situations and events. 




A number of researchers p9j-pT||43j have proposed location-based and movement- 
based prediction scheme for cache prefetching. These works predict the probability of 
user’s future query by analysing the user’s present and future locations (based on his/her 
movement prediction), the corresponding query history records, and the predefined user 
preference profiles. However, in reality, a user’s preference can dynamically be changed 
at runtime due to other factors. Moreover, the pre-defined static user preference profiles 
and rules are difficult to fulfil unanticipated situations (46) , unless the user is willing 
to adequately define many different preferences manually for all possible situations. In 
most cases, a user is unable to define his or her probability for events accurately (47). 
Therefore, a proper adaptive scheme is required in the prediction mechanism. 

5.7.2. Adaptation and Context 

Adaptivity is an important concern in the autonomous data prefetching approaches, 
especially in the resource-constrained mobile computing environments in which net¬ 
work bandwidth, and hardware resources (i.e., cache size, energy) are limited. With¬ 
out a properly designed strategy, a prefetching scheme may incur excessive resource 
costs (43||48||49). 

A number of researchers have proposed approaches to improve the adaptivity of their 
prefetching schemes in different aspects. An earlier work proposed by Jiang and Klein- 
rock (37) was concerned with system resource usage. In their approach, the prefetching 
behaviour was dynamically adjusted based on the access performance. In the work pro¬ 
posed by Pallis et al. (49), a policy and proxy-based prefetching strategy was proposed. 
Service consumers have been categorised into different cluster groups based on their in¬ 
terests, so the proxy can prefetch data more efficiently, and reduce the bandwidth cost. 
Yin et al. (48) proposed a value-based adaptive prefetch (VAP) scheme, in which each 
data item has been assigned a value. Based on the assigned value, the current remaining 
power level, the access rate, the update rate, and the data size, the system can evaluate 
the cost of prefetching, and adjust the prefetching decision dynamically. Hu et al. (50) 
proposed the Sliding Cache technique for adaptive prefetching, in which the cache space 
was dynamically changed based on the usage of the cached data item. Their evaluation 
showed that the approach can reduce the frequency of prefetching processes, and the 
results showed that the lesser the frequency of prefetching the lower the energy cost. 

Improving the accuracy of prefetching is one of the most important aspects to 
improve adaptivity. Drakatos et al. 63 proposed a context-aware cache management 
prefetching strategy. The proposed cell-based mobility scheme is capable of detecting 
user’s movement, and predicting use’s future location. Based on the predicted future loca¬ 
tion together with query patterns (previous query records), the system is able to prefetch 
data item more accurately. The authors have also mentioned that if a user’s preference 
model has been applied, the accuracy of prefetching can be explicitly improved. How¬ 
ever, further detail in this respect was not elaborated in their works. 

User preference profiling is one of the major aspects to improve the accuracy of the 
prediction strategy. When accuracy is increased, the overall adaptivity is also improved 
due to the resource costs being reduced. However, existing works (^[44] [51) did not 
consider the dynamism of the user’s preference. It is near impossible and inconvenient 
for most ordinary users to manually pre-define various preferences for all possible situa¬ 
tions. The system needs to autonomously compute user’s preference at runtime not only 
based on the historical query records, but also taking user’s current context into consid- 


eration. To overcome this challenge, our proposed strategy aims to dynamically predict 
user preference at runtime using context-aware mechanisms. 

5.2. Context-aware User Preferred Service Prediction 

The main technique that ensures the success of proactive service discovery in our sys¬ 
tem is the context-aware prediction scheme. The context-aware prediction scheme takes 
user’s current contexts as the basis, and then compares the current contexts to historical 
records to compute which query requested by the user has the highest probability. Each 
query recorded by the system has its associated semantic service type. By predicting the 
highest probable query, the system is capable of identifying what semantic service type 
is interested by the user in current environment. In this section, we describe our proposed 
context-aware prediction scheme. 

Definition 1: Raw Context Data — B. B = {bi : 1 < i < N}. A bi is the data retrieved 
from context providers such as Global Positioning System, Compass application, image 
sensor, video sensor, voice sensor, and so on. A bi will be used as the basic input param¬ 
eter to describe an interpreted context. 

Definition 2: Interpreted Context —C. C is a set of output from a rule-based context 
interpreting process, in which C = {cj : 1 < j < N}. Each cj E C consists of ID, type, 
value, and a set of associated raw context data B c . 

Based on Delir Haghighi et al.’s work (52), an interpreting rule consists of con¬ 
text type (type 01 ), the scope of raw context data value, which includes minimum 
value and maximum value, and the output represents the interpreted value from 
this definition. For example, an interpreting rule describes inputMin=”xl2yl4 ", 
inputMax="x37y22", type = "location", output ="MeetingRoom". 
When a retrieved location context contains a value: xl5yl7, which is within the scope 
of inputMin, and inputMax,the system will consider the location "Meet ingRoom" 
as one of the current contexts. 

Definition 3: Query Records — R. Each device should maintain a set of query records R, 
in which R = {r^ : 1 < k < N}. R represents the device user’s previous queries associated 
with corresponding contexts. Each record r^ consists of a query q rk and a collection of 
context information C rk occurred when q rk is submitted by the user. 

A q r]c represents a request query submitted by the user for invoking either an internal 
embedded Web service on his/her device or an external Web service provided by other 
mobile device peers within the network. A q rk consists of ID, parameters, and the cor¬ 
responding semantic Web service operation type. 

Definition 4: Raw Candidate Queries — Q. Q = {qi : 1 < l < N}. Q is a set of non¬ 
duplicate queries from R: 


1*1 

e= IK d) 

k= l 


When the Predictor component receives a set of contexts, it can predict the user’s 
query based on the comparison result between the current contexts and the contexts of 


each query record. User may also define a preferred query manually by setting a set of 
context and the corresponding query in a file, which will be loaded in the beginning of 
the process. If user’s definition exists, it will be used as the priority option. Otherwise, 
the system will perform the prediction automatically. 

Let C be a set of current contexts, where C = {di : 1 < i < N}. By applying Bayes’ 
theorem [[53 J, the probability of a qi G Q with one associated context Ci can be computed 
from (2): 
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where P{ci\qi) is the probability of c/ when qi was requested. It is computed from (3): 


P{ci\qi) = 
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P(qi) is theprobability number of occurrence of qi in R, in which P{qi) = k 

P(ci) is the probability of a random selected query that contains c/ as one of its 
attributes. It is computed from (4): 


P(c~i)= £ (P(ci\q n ) ■ P(qr k )) 

r k^ R 
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By considering all the involved context, the probability of qi (denoted by P(qi\C,R) will 
be refined as (5): 


P(qi\C,R)= £ 
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The calculation from (5) is based on considering the importance of all involved contexts 
equally. However, the importance of each context must be distinguished by different 
users. Hence, we apply the weight of context |52j in our scheme. 

Definition 5: Context Importance Rules —G. G is a finite set of rules, where G = {g m : 
1 <m<N}. Each g m consists of a corresponding context c 8m and a corresponding query 
q 8m , and the weight value denoted by v gm . 

v gm is a user-defined value in the context importance rules (G) for clarifying the 
importance of a context type to a query. By default setting, each context type has equal 
importance (set to 0) to all the queries. For example, a user may consider the location 
context to be more important to a query for searching the train arrival time. Hence, the 
user can increase the importance of the location context (e.g., set it to a number greater 
than zero) to the query to improve the prediction accuracy. Such a setting can also be 
applied globally. For example, user may prefer the location context should always be the 
primary consideration. Hence, whenever the prediction is performed, the location context 
will always be allocated a higher importance value than the other contexts. 

By applying the weight of context, the final formula has been refined in (6). 
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where Y, v g m is the sum of a set of v gm in which v gm ^ 0 . v c g ^ 1 denotes one of the defined 
rule, where v c g ^ 1 g m £ G, c gm = q A q gm = qi. 

In order to let a user have enough control on the autonomous decision-making based 
on the prediction model, the user can manually define Context Filtering rules. A Context 
Filtering rule consists of a query type, and a list of contexts that should be ignored in the 
calculation. For example: A user is searching for the recommended food in the current 
area. For this search query, weather context and temperature context can be important if 
the food seller type is an outdoor bazaar, or it does not have enough indoor seats when 
customers are required to queue outside. On the other hand, a similar search method may 
not be influenced by weather and temperature if the query specifies the search criteria as 
“restaurant” + “indoor”. 

If user defined rules exist, in the prediction algorithm, the current contexts C for a 
query qj will be redefined to reflect whether a context should influence the qi or not. For 
example, current contexts C consists of c\, c~ 2 , C 3 , and c\. If user has defined that c\ has 
no influence to query type q y , when the prediction algorithm computes the P{q y \C,R) 
(see ( 6 )), C will be redefined as {c\,C 2 ,cf\ excluding c\. 

A prediction scheme that relies on the user’s historical record usually has a limitation 
in which the accuracy of the prediction can be low when there is not enough records. 
One solution is to apply social context. Social context represents the factors that can 
potentially influence a user’s decision. For example, a friend / of a mobile user u , might 
have similar interest to u , and / might have been to the same place as where u is currently 
arriving. Since / and u are similar, they may prefer to interact with the same type of 
services at that location. 


6. Trustworthy Service Discovery for MSNP 

This section presents a scheme to improve the speed of trustworthy service discovery 
in service-oriented MSNP by reducing transaction overhead and not relying on message 
forwarding in order to avoid the issues caused by unstable connectivity and resource 
constraint. 

6.1. A Lightweight Trustworthy Service Discovery for MSNP 

The fundamental strategy to reduce the transaction overhead in MSNP is to utilise the se¬ 
lective trust reputation rating recommender scheme similar to existing works. However, 
we need to address two additional issues: 

(1) How can MSNP participants share their reputation rating data? 

(2) How can a requester limit the number of its recommenders in the friend-based repu¬ 
tation model and in a public-based reputation model? 

The later sections involve a number of elements. Hence, we define the meaning of the 
elements first. 



Definition 6: Service Provider — SP. An SP is an MSNP participant that provides WS. 
It is defined as a tuple (ID, services) where: 

— ID denotes the identity of the SP 

— services = {servicei : 1 < i < IN} represents a set of WS provided by the SP. 
Each service has a name denoted by SName and a semantic service type denoted 
by SType 

Definition 7: Previous Interacted Service Consumers List — PSC list. PSC = {(cidj,IRj) 
1 <j< IN}. An SP can optionally provide its PSC list to let the others know who have 
been using its services. A PSC is defined as a tuple ( cid,IR ) where: 

— cid denotes a service consumers’ identity 

— IR denotes interaction records between the service provider and service con¬ 
sumer, e.g., IRj denotes a list of interaction records between the SP and the ser¬ 
vice consumer cidj 

Definition 8: Service Provider Ratings — SPR.SPR = {(ID^Ratesk) : 1 < k < IN} 
where: 


— IDk denotes the identification of S7\ 

— Ratesk = {(service], rate]) : 1 < l < IN} is a list of rating values of SP^s services 

— service] denotes one of the SPk s services 

— rate] denotes the rating value of service] 

Definition 9: Recommended References — RR. RR = {(SType m ,ID m ) : 1 < m < IN} 
where: 


— SType denotes a semantic service type 

— ID m = {id™ : 1 < o < IN} denotes a list of MSNP participants’ IDs that are 
recommended as the rating reference for SType m services 

Definition 10: Reputation Rating Data — RD. Each MSNP participant has a RD file in 
its device local storage as well as its cloud storage synchronously. An RD file contains 
two sets of data— SPR and RR. 


Listing 1: Simplified RD example 


<key>Service Provider Rating</key> 

<value> 

<key>SPID</key> 

<value> 

<key>URI</key> 

<value> 

<key>type</key><value>semantic type value</value> 
<key>Rate</key><value>rating value</value> 
<key>transaction records</key> 

<value>< !— URI, service type, time etc. —x/value> 
</value> 

</value> 

<!-- Other interaction records ... —> 

</value> 

<key>Recommended References</key> 

<value> 



<key>Semantic Service Type</key> 

<value> 

<key>ID</key><value ><!—URL of RD —></value> 
<!-- other IDs ... —> 

</value> 

<!— Other types ... —> 

</value> 


Listing 1 illustrates a simplified RD in hash map format. An RD file can be obtained 
from either friends or other proximal MSNP participants. The prerequisite condition is 
how the requester agent retrieves the RD from the other agents (either from friends or 
public proximal participants). In a generic Mobile Ad Hoc Network environment, it is 
commonly assumed that the requester agent will collect the RD by broadcasting or mul¬ 
ticasting its request message to the other participants’ agents. This is not always applica¬ 
ble in MSNP. Fundamentally, MSNP operates in a dynamic public MP2P environment in 
which participants may not always be available. For example, when the requester agent 
intends to request a list of friends’ agents for the RD , there may only be a few of them 
online. Another example, when the requester agent intends to request a list of proximal 
MSNP participants’ agents for the reputation rating data, many may not even respond to 
such a request because they may have disabled such an operation to save their battery 
power. 

To resolve the basic data retrieval problem in MSNP, each MSNP participant can 
utilise one or multiple backend public accessible cloud storage services to provide its RD 
to the others. The URL of the RD can be simply described in SDM. Hence, while the 
requester agent retrieves Service Description Metadata (SDM; e.g., WSDL) in the first 
phase of service discovery process, it can already identify where to retrieve the reputation 
rating data provided by the other proximal participants. As for the friends’ RD, since the 
requester has close connection with them, the requester would have already replicated 
their SDM files. Therefore, the requester agent always knows where to retrieve the RD 
of the requester’s friends. 

One aspect in MP2P trust that was not addressed in most existing works is how ser¬ 
vice providers actively participate in the trustworthy service discovery processes. In real 
world services, providers always attempt to encourage consumers to use their services 
by using various schemes such as showing customers’ rating and reviews of their prod¬ 
ucts and services. Although in an MP2P trust system, service providers should not hold 
the rating of their own services j54j], they can still provide a list of previous interacting 
service consumers. 

When a requester intends to retrieve a service provider’s reputation rating, the ser¬ 
vice provider can provide a PSC list. The requester can use the cid of PSC list to collect 
RD instead of collecting all the RD of friends or proximal strangers. This approach can 
reduce unnecessary data transmission. Moreover, MSNP agents can identify that a ser¬ 
vice provider who does not provide the PSC list can potentially be a malicious node un¬ 
less the service provider is new to the MSNP. If an MSNP participant is new, it may not 
have any interaction record with any other participants either as a service consumer or as 
a service provider. Hence, if an MSNP participant is not new, and it does not provide the 
PSC list, then this MSNP participant’s service can be identified as potentially malicious. 
This notion is based on the reputation system of general online trading/shopping ser- 



vices such as eBa>p^|or Yahoo Auction Japaip] In the case of only one matched service 
provider found in the network, and it is a new MSNP participant, the agent should notify 
its user and let the user decide whether to invoke the service or not. 

Considering the situation when a dishonoured service provider may provide an in¬ 
complete PSC list, which only describes a list of good records, the requester agent should 
not refer to the service provider’s PSC list to identify the service provider’s trustworthi¬ 
ness in the following cases: 

• In the case of recommendation from friends: If none of the cid found in PSC 
belongs to the requester’s trusted friends, the PSC should not be used. 

• In the case of recommendation from public: If none of the cid found in the PSC 
belongs to highly creditable strangers, the PSC should not be used. 

The following sections describe the proposed scheme for trustworthy service dis¬ 
covery in service-oriented MSNP. 

6.2. Selecting Recommenders Based on Friends and FOAF 

Due to privacy issues, the information about a person’s trust rating value to his/her friends 
may not be accessible to other friends. For example, in Facebook, a user can hide all their 
posts from a friend and the friend will not know. Although the trust rating value is not 
accessible, the person can still provide a list of friends as RR for a particular service type. 
The friends’ Identifications (IDs) assigned in RR denote that the owner of RR trusts this 
list of participants’ judgement for a particular service type based on their past experience. 

RR is generated and updated when an MSNP agent performs service by referring 
to the RD of its user. RR only contains the IDs of trusted friends for a particular service 
type. If a friend in this list has given a high rating to a bad service provider, the friend’s 
ID will be removed from the list. As a simple example, the MSNP application lets user 
manually block a service provider ID. When a service provider ID is blocked, the friends 
who gave a good rate to the service provider will be removed from the corresponding 
Recommended References. On the other hand, when the list is empty and the recom¬ 
mendation was from randomly picked friend, if a friend’s recommended service provider 
gives satisfactory recommendation to the requester, the friend’s ID would be added to 
the list. 

There are two approaches to assign friends to RR\ 

(1) Based on experience. Since an RD provides a list of ratings, an agent is capable of 
identifying which friend of its user has the highest service interaction experience 
with a specific service type. 

(2) Based on similarity. A user can assign their friends to RR based on how similar their 
past rating to a particular service type, i.e., using Pearson Product-moment Correla¬ 
tion Coefficient. For example, userA’s past rating is very similar to user B. user C 
intends to refer user A's rating to service provider— H who provides K type service. 
Unfortunately, user A does not have experience with H. However, since user B’s rat¬ 
ing is similar to user A, user A has already assigned user B as RR of K type service. 
Hence, user C will refer to user B’s rating to identify the trustworthiness of H. 


22 See http : / /www. ebay. com/J_ 

23 See http : //auctions . yahoo . co . jp/ 



The rating seminaries between two users —A and B —can be computed by using 
Pearson Product-moment Correlation Coefficient below: 
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where S is the set of all the services rated by both A and B. rateA-^s is A’s rating to service 
s eS. rate a is the average rating rated by A to all services, rates^s is B’s rating to s e S, 
and rateB is the average rating rated by B to all services. 

Note that both approaches require a fair number of friends’ RD replicated previously. 
For example, a user can replicate their friends’ RD at home, then their agents can apply 
the approaches to identify RR before the user using MSNP application outside. 

The following algorithm outlines the steps for a requester to identify the trust score 
of a service/content provider’s service s £ S. 

Algorithm 1: 

Step 1. Identify a list of friends who have experience with service —s. 

1.1. Requester retrieves PSC of the provider of s (PSC s ). We expect that the re¬ 
quester has a list of friends’ IDs (denoted by FID , where FID = {fidj : 1 < j < 
N }) stored in the local memory of the mobile device. 

1.2. By searching the intersection between all the cid in PSC s and FID , requester 
can find a list of friends who have service invocation experience with s— MFID , 
where MFID = FID fi CID. If \MFID\ = 0 then the process goes to Step 3. Oth¬ 
erwise, continue with Step 2. 

Step 2. Identify matched recommended references. 

2.1. As described previously, each MSNP participant has a RD. Let MRR = {rr £ 
RR : SType rr = SType s }, where SType s is the semantic service type of s that the 
requester intends to invoke. RR is a list of friends’ IDs that are recommended for 
identifying the reputation of a type of SType s . 

2.2. Let RrlD = MF IDF MRR. From RrlD , the requester agent can identify the 
recommended friend(s) for SType s that also have experience with s, and refer the 
friend’s rating to s. If \RrID\ = 0, the process goes to Step 3. 

Step 3: Referring recommendation from recommended friend’s FOAF. When the re¬ 
quester’s direct friends do not have experience with s , the requester will refer to the 
reputation rating from FOAF. 

3.1. Identify a friend with the highest experience as a recommender and then based 
on the recommender’s RD to find the friend of the recommender who has the 
highest experience with SType s and who also has rated s. 

3.2. Once the FOAF is found, the requester will refer to the FOAF’s rating of s. 
However, if none of the FOAF has experience with s then the process will pro¬ 
ceed to the scheme described in Section 6.3—Selecting recommenders based on 
public. 



6.3. Selecting Recommenders based on the Public 


In this section, we describe the scheme to identify a service provider SP's reputation 
score based on the public proximal MSNP participants’ ratings. 

Definition 11: Credibility — Cr. An MSNP participant’s Cr, which is rated by the other 
peers, represents its reputation as a recommender for a type of service. The more MSNP 
participants’ IDs shows up in the RR of every peer’s RDs, the higher the MSNP partici¬ 
pant’s credibility is for being a recommender of the corresponding service type. 

Algorithm 2 describes the scheme for selecting trustworthy recommenders from 
public proximal MSNP participants. 

Algorithm 2: 

Step 1: Generating a candidate recommender list. While the requester performs the ser¬ 
vice discovery process to find service providers who can provide the service of interest, 
the requester is also retrieving the RD of each proximal MSNP agent. This step consists 
of the following two tasks: 

1.1. Let PRRD be the set of RDs retrieved from all proximal agents. PRRD = 
{prrdi : 1 < i < N} where prrdj denotes the RD of each agent pi. For each 
prrd G PRRD , the requester agent can identify that whether a pi has interaction 
experience with service provider s or not. 

1.2. Let MPR denotes the matched PRRD in which MPR = {prrdj G PRRD\ID G 
SPRj = ID S }. ID S denotes the ID of service provider s. If ID S is found in one of 
prrdj' s SPR but not in the PSC list of the provider of s, then either the prrdj is 
dishonoured or the provider of s is dishonoured. 

Since the aim of this scheme is to identify the trust of s's provider, the final result will 
show its reputation score. However, dishonoured rating from the other participants will 
affect the accuracy of the scheme. Hence, the requester agent has to identify a recom¬ 
mender’s trustworthiness before referring its reputation rating. Step 2 describes the pro¬ 
cess to identify a recommender’s trustworthiness based on credibility. 

Step 2: Identify the credibility of a candidate recommender. A proximal MSNP partic¬ 
ipant’s credibility is computed based on the other proximal MSNP participant’s rating. 
Suppose we want to compute a proximal MSNP participant pj's credibility, we will use 
PRRD excluding the RD of p\. We use CRRD to represents such a set of data, where 
CRRD = {crrd m : 1 < m < N}. Step 2 consists of the following two tasks: 

2.1. Let Cr p be the credibility of p , and Cr p is computed by the formula below: 


Cr p = |{crrd G CRRD\ID^ = ID p }\ (8) 

where ID C rrd m denotes an MSNP participant’s ID in the RR of crrd m , and ID P 

rr 0 y 

denotes p’s ID in MSNP. 

2.2. Once the credibility of each PRRD' s owner pi is computed, the process goes to 
the next step. 



Step 3: Identify the experience of a candidate recommender. People trust a person who 
has more experience about a specific subject. In existing works such as TEMPR |3l| , 
the experience of p is directly related to the number of successful interactions completed 
between p and the service provider. Here, we consider the experience based on the type 
of service instead of a particular service provider’s service. Because in the real world, 
a person may not use a service the second time when he/she had a bad experience with 
the service the first time. However, the person may have a lot of of experience using the 
same type of service provided by many different providers. Hence, the person’s opinion 
is still valuable. For example, the review of a senior computer machine reviewer, who has 
over 100 reviews of notebook computers from different brands, is often being considered 
as more trustable than a junior reviewer who has only reviewed less than 10 notebook 
computers. Based on this assumption, the experience of p in our model is based on p’s 
experience to a particular service type. This step involves the task below: 

3.1. Let STypeExp^s be pf s experience to SType s . The experience value of pi to 
SType s is computed by: 

STypeExp^s = \{irf Pi € IR R[>1 ’' : STypef Pi = SType s }\ (9) 


where 

— IR RD Pi is the interaction records of pi , in which 

IR RD P i = { j r RD P‘ : 1 < l < N}. 

— SType^ Pi denotes the service type of the invoked service recorded in irf ° Pi . 

Step 4: Compute the trust score of a candidate recommender. The trust score of an 
MSNP participant is the average of its normalised credibility value and its normalised 
experience value. The normalised value is computed based on the overall comparison 
from all the other participants in P. This step involves the following two tasks: 

4.1. For a particular MSNP participant— (p G P as a recommender of a service type 
(TV), the trust score Try of (p is computed by the formula: 


Try = avg 


Cry 

C r Pi 


STypeExy^ s \ 

LpiepSTypeExpi^s) 


( 10 ) 


where 

— Cry is (p’s credibility value. 

— H Pi epC r P i denotes the sum of credibility values of all pi. 

— STypeExy^ s denotes the experience of (p for SType s . 

— T, Pi eP STypeExp.^g denotes the sum of all pi s experience for SType s . 

4.2. Based on the computation result, the requester can choose a number of MSNP 
participants that have the highest Try value to be its recommender to compute the 
reputation score of s. 




7. Evaluation 


For proof-of-concept, we have developed and evaluated a prototype consisting of the 
components composing the mechanism described in our schemes. This section presents 
the evaluation methods and results of our prototype. In order to show the detailed evalu¬ 
ation of each proposed scheme, we have tested each component individually. 

7.7. Prototype Implementation 

The prototype was developed using the objective-C programming language and was 
tested on Apple iPod Touch 4th generation and Apple iPhone4S. 

The basic mechanism which lets MSNP agents participant in the service-oriented 
MSNP is Mobile Web Service (MWS). Depending on the user preference, an agent can 
either support the simple MWS client-side mechanism only to discover and invoke ser¬ 
vices or support both MWS client-side and MWS server-side mechanisms. The imple¬ 
mentation of the MWS mechanism are described below: 

The MWS provided by each MSNP agent in the prototype is RESTful Web service. 
An advanced MSNP content consumer or a content provider is able to be an MWS host. 
In the prototype, an MWS host consists of two main components: 

• HTTP Web server 

We used CocoaHTTPServeiF^I API to enable the HTTP server mechanism. The 
advantages of using CocoaHTTPServer are: (1) it supports asynchronous socket 
communication, which can improve the speed of data transaction; (2) it supports 
Bonjour service publication. Web services provided by CocoaHTTPServer are 
discoverable by the Bonjour service discovering mechanisms. In the prototype, 
we use Bonjour as the main mechanism for MP2P service discovery. The HTTP 
Web server in prototype will respond with a S AWSDL document when the request 
message does not specify a particular path/operation name. 

• Semantic Web service protocol 

SAWSDL and OWL documents play an important role in MSNP. In order to en¬ 
able autonomous service discovery and filtering, an MWS host is required to be 
able to process XML-formatted SAWSDL and OWL. We used Google Data APp] 
to process XML-formatted data. Google Data API provides a fully functioned 
XML parsing mechanism. The SAWSDL and OWL data used in the prototype 
were written manually because there is no tool available to generate SAWSDL 
automatically from the source code written in Objective-C. 

The basic functions of an MSNP agent are: to discover other MSNP agents in its 
current network; and to invoke Web services provided by the other agents. In order to 
support the two functions, we have implemented two components: 

• Web service invocation component 

It supports two asynchronous HTTP method invocation mechanisms (GET and 
POST), which is compatible with RESTful Web services. 


24 https://github.com/robbiehanson/CocoaHTTPServer 
25 https://developers.google.com/gdata/ 



• MP2P service discovery component 

The prototype used Bonjour technology to support MP2P service discovery. Each 
MSNP agent has a Service Pool component to monitor the current network. The 
Service Pool component utilises <NSNetServiceBrowserDelegate> to 
monitor the published MWS (by MSNP agent) in the Bonjour network. It man¬ 
ages a list of pushed MWS names. Depending on the discovery approach, it may 
automatically retrieve the SDM of each newly joined MSNP using the Web ser¬ 
vice invocation component. 

Evaluating the performance of service discovery may involve hundreds of MSNP 
agents. We did not have a large number of mobile devices to realise such an environment. 
However we have deployed hundreds of MSNP agents in a Macbook Aluminium 2008 
version with Intel Core 2 Due 2.4 GHz CPU and 4GM RAM to simulate the environment. 
The wireless network for evaluation is on IEEE 802.1 In 2.4GHz Wi-Fi environment 
controlled by an Apple Airport router which is Internet connection-enabled. 

The following sections provide details on how each component was evaluated in 
order to present the proof-of-concept of our proposed schemes. 

7.2. Proactive Service Discovery Performance 

In Section 4.3, the user preference associated push-based service discovery 
(PrefPush ) approach was described. The Pref Push-based service discovery approach 
utilises the context-aware user preference prediction scheme to let the requester agent 
provides its user preferred semantic service type to other service/content provider agents 
in the network. The approach can reduce the required metadata processing on the 
requester-side, hence, reducing the service discovery timespan of the requester agent. 

In order to show that the proposed PrefPush- based service discovery approach can 
provide a better performance than the other two basic approaches— Pull and Push. We 
have performed an experiment in a simulation environment to compare the performance 
(timespan of service discovery process) and the costs (CPU usage and RAM usage) of 
the three approaches. 

First, we re-iterate and describe the implementation details of the three approaches 
below: 

• Pull , as described in Section 4.1, enables an MSNP requester agent who intends 
to search for a cType service in an MSNP environment to use active invocation to 
retrieve the other service provider agents' service description metadata (SDM) in 
order to identify which agent( s) can provide the cType service. In our setting, we 
assume each service provider agent has its own OWL file to describe its semantic 
type. Hence, the requester agent has to retrieve both SAWSDL and OWL from 
each service provider agent. 

• Push, as described in Section 4.2, allows the MSNP requester agent to utilise 
MWS to passively receive and process SDMs advertised by the other service 
provider agents. 

• PrefPush , as described in Section 4.3, is fundamentally similar to the Push ap¬ 
proach. However, the requester agent is also able to provide user preferred ser¬ 
vice type to the other service provider agents. In this approach, the semantic type 
parsing process is performed by the service provider agents. 



In our experiment, we did not include the Hybrid approach (described in Section 
4.4) in the comparison because the main purpose of the Hybrid approach, which utilises 
both Pull and PrefPush concurrently, is to guarantee that the requester agent is still 
capable of performing service discovery in an MSNP environment when the other agents 
do not support the PrefPush-based approach. In other words, it provides a fall back 
mechanism. 

7.2.7. Settings 

The experiment was performed mainly on an iPhone4S with IEEE802.11n 2.4 GHz Wi¬ 
Fi environment. We simulated the other proximal MSNP participants by deploying a 
number of MSNP agent hosts on a Macbook. 

The MSNP agent , which has been installed in the iPhone4S, represents the service 
requester who is searching for MSNP agents who can provide the service that match a se¬ 
mantic service type— cType. The proximal MSNP participants’ MSNP agents are of two 
types: normal and matched. The normal MSNP agents do not provide cType services 
and the matched MSNP agents can provide cType services. Every MSNP agent (includ¬ 
ing the requester and the others) provides two service description related documents— 
SAWSDL and OWL. The size of SAWSDL is 6KB and the size of OWL is 12KB. 

The experiment consists of two tests: performance and resource costs. 

• For the performance, we aimed to compare the timespans to successfully discover 
matched service providers from all the deployed MSNP agents in the network. 
We deployed a different number of MSNP agents on the Macbook to evaluate the 
three different approaches: Pull , Push and PrefPush. 

• For the resource cost testing, we aimed to compare the CPU and RAM usages 
between the three approaches. It was done by recording the CPU and RAM usages 
while performing the service discovery processes. 

Note that in the description of Section 4.1, we have mentioned SDM caching. SDM 
caching can reduce transaction overheads for all approaches equally if implemented. 
Since the aim of our tests is to compare the three approaches solely, we did not include 
the caching mechanism. 

7.2.2. Performance Comparison 

This section presents the experimental result of the service discovery timespan compari¬ 
son among the three approaches, as shown in Figure 6. 

In the figure, x-axis represents the number of service provider agents deployed in 
the network. Each deployed group has 4/5 normal agents and 1/5 matched agents. For 
example, when 500 service provider agents were deployed, while 400 out of 500 were 
normal agent, 100 out of 500 agents were matched agents who can provide cType ser¬ 
vice. The y-axis represents how long it took the requester agent to discover the matched 
service providers. 

The result shows that when there were only 50 service provider agents in the 
network, Pull provided the best performance. However, when the number of service 
provider agents increased, the performance of Pull worsened because of the increased 
amount of SDM retrieval and semantic data processing. Push utilised MWS to receive 
SDM from the other service provider agents. Although the requester agent in the Push 
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Figure 6. Timespan Comparison 


approach also had to process SDM, the overall timespan was much lesser than Pull when 
the environment consisted of a large number of service provider agents. Among the three 
approaches, our proposed PrefPush approach outperformed the other two when the en¬ 
vironment consisted of 100 or more service provider agents. 

7.2.3. Resource Usage Comparison 

This section presents the comparison of the CPU and RAM usages of the three ap¬ 
proaches. In our setting, we deployed 1 matched service provider agent and 4 normal 
service provider agents every 1 second continuously for 100 seconds. We recorded both 
CPU usage and RAM usage within a period of 100 seconds. 



Figure 7. CPU Usage Comparison 


Figure 7 illustrates the CPU usage record comparison among the three approaches. 
As the graph shows, Push had the highest CPU usage while PrefPush consumed the 
least CPU resource. 

Figure 8 illustrates the RAM usage comparison among the three approaches. As 
the result shows, the RAM usage of the three approaches increased continuously. Pull 
consumed the highest RAM resource, while Push and PrefPush have very similar RAM 
resource consumption. 
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Figure 8. RAM Usage Comparison 


In order to highlight the difference between Push and PrefPush , we enlarged the 
graph to show the RAM usage between 40 to 60 seconds for Push and PrefPush. This 
is shown in Figure 9. 
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Figure 9. Partial RAM Usage Comparison of Push and PrefPush 


In the figure, Push shows a slightly higher RAM usage than PrefPush. 

7.3. Context-Aware User Preference Prediction 

This section presents the evaluation results of the component that enables the context- 
aware user preference prediction scheme presented in Section 5.2, which is the main 
component for enabling the proactive service discovery in MSNR The scheme uses cur¬ 
rent environmental context information to compare with the past context information as¬ 
sociated with the service invocation records to predict what types of services may be of 
interest to the user in the current environment. 

The test focused on evaluating the accuracy of the prediction scheme using two 
different datasets: the programme generated dataset and the epSICAR-datasej^] 


2 e http: / /www. imada . sdu . dk/ ~gu/ 






























7.3.1. Evaluating the Scheme on Programme 
Generated Dataset 

In order to test the accuracy of the scheme, we have created a user query record generator 
to simulate user query records and the associated context information. Table 1 illustrates 
the basic parameters used in the record generator. 


Record 

Query 

CL 

CT 

CA 

CW 

CP 

TypeA 

Ql 

LI 

Tl 

A1-A5 

W1-W5 

P1-P5 

TypeB 

Q2 

L1-L5 

T2 

A2 

W1-W5 

P1-P5 

TypeC 

Q3 

L1-L5 

T1-T5 

A3 

W3 

P1-P5 

TypeD 

Q4 

L1-L5 

T1-T5 

A1-A5 

W4 

P4 

TypeE 

Q5 

L5 

T1-T5 

A1-A5 

W1-W5 

P5 


Table 1. Parameters for Prediction Test 


We defined five types of records. Each record type describes a particular query type and 
five types of associated context information values denoted by CL, CT, CA, CW and CP. 
The record generator will randomly generate a given number of records (e.g., 100, 200, 
300, etc.). Each record consists of one query type and five context values. For example, 
considering the setting in Table 1, the record generator will randomly select a record type 
from A to E. If the selected record type is A, then the query type will be Q1 and the 
associated context information will be CL=L1, CT=T1, CA = a random value from A1 to 
A5, CW = a random value from W1 to W5, CP = random value from PI to P5. The two 
static values (LI and Tl) represent the contexts that will influence the user’s decision to 
select Ql. 
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Figure 10. Prediction based on random dataset 

Figure 10 illustrates the results of our evaluation using the parameter setting in Table 
1. The x-axis shows the percentage records we have used as training set to predict the 
rest of the records. For example, the very first value on the bottom left of the graph shows 
the accuracy result based on a total of 100 query records, of which 60% records were 
used as the training set to predict the rest of the records (40%). The prediction accuracy 
for this is around 84%, as shown on the y-axis. 






















7.3.2. Evaluating the Scheme on epSICAR Dataset 

We have also tested our prediction scheme using a subset of epSICAR dataset. We used 
200 sequence records from the dataset. Each record consists of two context attributes: 
location and action. Each record is also associated with corresponding object (e.g., Hi- 
Fi Music system for listening music in living room), which can be considered as a ser¬ 
vice. The test result is shown in Figure 11. In the figure, when 30% of the records (i.e., 
60 records) were used as training set to predict the rest of the records, the accuracy of 
prediction was close to 100% rate. 



Percentage of records used as training set 
Figure 11. Prediction based on real dataset 

7.4. Trustworthy Service Discovery in MSNP 

This section presents the evaluation of the main component of the lightweight trustwor¬ 
thy service discovery scheme. The evaluation consisted of two parts: 

1. We evaluated the proposed scheme described in Section 6.2, in which a requester 
intends to obtain the trust score of a provider based on the requester’s friends and 
friend of a friend (FOAF) (i.e., recommendation based on friends and FOAF). 

2. We evaluated the proposed scheme described in Section 6.3, in which a requester 
intends to obtain the trust score of a provider based on public proximal MSNP 
users who are non-friends of the requester (i.e. recommendation according to the 
public). 

We describe our evaluation approach below: 

(1) For each user record of a trust rating dataset, we considered the user as a requester 
in MSNP who had a set of trust rating records (denoted by R-set) which corre¬ 
sponds to the Reputation Rating Data (RD) in Definition 10. 

(2) From the R-set, we separated the records into two subsets: rating of friends and 
rating of non-friends. 

(3) From the rating of non-friends subset, we used the proposed schemes (described 
in Section 6.2 and 6.3) to predict what was the requester's rating for each rating 
of non-friends. 

(4) We also used the basic schemes (i.e., by simply referring to the ratings from all the 
rating of friends or all the friends of the corresponding users of rating of friends) 
to predict what was the requester's rating for each rating of non-friends. Then we 
compared the results between the proposed schemes with the basic schemes. 












(5) Finally, we compared the data transaction costs between the proposed schemes 
with the basic schemes. We then applied a basic CPI model to compare the 
schemes. 

In order to evaluate the proposed trustworthy service discovery scheme for MSNP, 
we have used the Advogatcp] dataset to simulate a large number of MSNP users’ trust 
rating data. 

Advogato dataset is part of the Trustlet project (55), which collects the trust rating 
values of social network site users since October 13 2007. Each record in the Advogato 
dataset consists of: 

• The ID of the person who rated another person 

• The ID of the person who has been rated 

• The rating value, which has three possible levels suggested by (55) : Apprentice 
(represented by a score of 0.6), Journeyer (represented by a score of 0.8), and 
Master (represented by a score of 1.0). 

We have tested our proposed trustworthy service discovery scheme using the Ad¬ 
vogato dataset of 26 May, 2013. The original dataset contains many records with empty 
rating values (Some users have not rated any other users). Since our proposed scheme 
requires a fair number of rating data to calculate the trust score of a person based on 
other users’ ratings, we have removed users who have less than 10 rating records from 
the original dataset. 

The original Advogato dataset does not specify the relationship between users (i.e., 
are they real friends or not?). However, from their trust ratings, we categoried the rela¬ 
tionship of users into two groups: when two users rated each other as ‘Master’ level, they 
are ‘friends’. Otherwise, they are ‘non-friends’. 

The following sections present the evaluation cases and results. 

7.4.1. Selecting Recommender Based on Friends and FOAF 

The aim of this test is to show that the proposed schemes (described in Section 6.2) 
require less transaction cost but still can provide similar trust score measurement result 
as the basic schemes. 

The basic schemes use a simpler approach to determine a service/content provider’s 
trustworthiness based on the reputation rating of all the requester’s friends or all the 
requester’s FOAF. They are: 

• All Friends (AF). 

In this scheme, the requester computes a service provider’s trust score based on 
the average rating values of all the requester’s friends who have rated the service 
provider. 

• All Friends of Friends as Recommended Reference (AFOAF) 

In this scheme, the requester computes a service provider’s trust score based on 
the average rating value of all Recommended References (RR) of the requester’s 
friends. The RR in this scheme are simply the FOAF who have rated the service 
provider without additional filtering. 


2 ^http://www.trustlet.org/wiki/Advogato_dataset 



The proposed schemes , which correspond to Step 2, 3 and 4 of Algorithm 1 are: 

• One High Experience Friend (HEF) 

In this scheme, the requester computes the service provider’s trust score based 
on one single High Experienced Friend found from the requester’s friends who 
have rated the service provider, and have largest rating records in the friends. HEF 
corresponds to the description in Algorithm 1, Step 2. 

• One High Experienced FOAF (HEFHEF) 

In this scheme, the requester computes the service provider’s trust score based 
on one single High Experienced FOAF who has rated the service provider. The 
High Experienced FOAF is a friend of a HEF who may not have rated to the 
service provider, but the HEF has one or more friends who have rated the service 
provider. This scheme corresponds to Algorithm 1, Step 4. 

• One Most Similar Friend (MSF) 

In this scheme, the requester computes service provider’s trust score based on one 
single most similar friend. This scheme corresponds to Algorithm 1, Step 3. 

In this test case, we firstly retrieved a list of user IDs (as requesters) from the dataset. 
Each user had a list of ratings consisting of the IDs of the persons who had been rated, 
and the corresponding rating level value. Our test focused on predicting the requester’s 
rating of each ‘non-friends’ (representing service providers who will be evaluated by the 
requester) based on ‘friends’ and ‘FOAF’. 

We used the above five different schemes to perform the prediction to show that 
the proposed scheme, which utilises the High Experience Friend’s rating and the High 
Experience Friend’s Recommended Reference person’s rating (Algorithm 1) are efficient 
approach to measure the trust score of a provider. 

We assumed that the requester has replicated friends’ RD in local memory previ¬ 
ously. Hence, at runtime, it can identify recommenders for computing the reputation 
score of a service provider without retrieving all friends’ RD directly from the friends’ 
MWS or their cloud storages. The replicated RD can only be utilised to identify rec¬ 
ommenders. In order to find out the up-to-date reputation rating score from the recom¬ 
menders, the requester still has to perform the request to retrieve the necessary RD di¬ 
rectly from the friends’ MWS or their cloud storages. Depending on the scheme used, 
the required RD-retrieval process can be different. 

Table 2 summaries the cases of different schemes that were used for testing and com¬ 
parison. The Comparable Count in the table represents the total number of rating records 
that have been used to test the scheme. Because each scheme relies on different criteria, 
the Comparable Count differs. For example, not all the users have available friends or 
FOAF’s ratings to predict the trust rating of a specific user. Hence, such incomparable 
records have been excluded in the testing for that scheme. 

The values of ‘Average Minimum Transaction Required’ in Table 2 were computed 
as follows: 

• AF scheme requires up-to-date reputation rating values from all friends. The av¬ 
erage minimum transaction required is equal to the average number of friends of 
each requester under test, in which the average number of friends each requester 
has is 6, which is the average number of ‘Master’ level ratings of each user in the 
Advogato dataset. 



Scheme 

Comparable Count 

Prediction 

Accuracy 

Average Minimum 
Transaction Required 

Basic 

AF 

1010 

0.633569 

6 

AFOAF 

1075 

0.642984 

36 

Proposed 

HEF 

1010 

0.635335 

1 

HEFHEF 

1010 

0.640418 

6 

MSF 

1010 

0.579199 

1 


Table 2. Comparison of Trust Schemes’ Accuracy and Transaction Costs of Friends and FOAF 


• AFOAF scheme requires the highest transaction cost at runtime incurred by re¬ 
trieving the up-to-date reputation rating values from all FOAFs. The total cost of 
the required transaction was the number of friends multiplied by the number of 
FOAF, which is 36. 

• In HEF scheme, since the requester has replicated the RD previously, the repli¬ 
cated old RD is sufficient for the requester to identify a HEF at runtime without 
consuming data transaction cost on retrieving new RD via the Internet. Once a 
HEF is found, the requester only needs to retrieve the up-to-date reputation rating 
value from the HEF. Hence, in this case, the transaction cost is 1. 

• HEFHEF scheme requires the minimum transaction values is 6, which is the sum 
of the transaction cost of retrieving RD from all friends of HEF. 

• MSF scheme incurs the same transaction cost as the HEF-based scheme. 
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Figure 12. Predictive Rating Accuracy Comparison of Different Schemes based on Friends and FOAF 

Figure 12 summarises and compares the prediction accuracy and the transaction cost 
of the five schemes in graphical form. 

In order to highlight the overall improvement of the proposed approaches (HEF, 
HEFHEF, MSF) compared to the basic approaches (AF, AFOAF), we have translated 
the results into a cost and performance index (CPI) model. Figure 13 shows the cost- 
performance index value of each approach. As the figure shows, when direct friends 






Figure 13. Cost and Performance Comparison of Different Schemes based on Friends and FOAF 

are available as the recommenders of the reputation rating, the proposed HEF and MSF 
schemes provide better CPI values than the basic scheme—AF. When direct friends can¬ 
not be the recommenders, during which FOAF is needed, the proposed HEFHEF scheme 
gives a better CPI value than the general AFOAF scheme. 

7.4.2. Selecting Recommenders Based on the Public 

The test described in this section corresponds to the scheme described in Algorithm 2, 
in which a requester is unable to determine a service/content provider’s trustworthiness 
based on friends or FOAF’s reputation rating values. Hence, the requester will refer to 
proximal strangers for the reputation rating values. However, the reputation rating of 
random selected stranger is unreliable. Hence, we presented in Section 6.3 an approach 
to identify which strangers’ reputation rating values are reliable based on the stranger’s 
experiences and credibilities. 

This test aims to show that the proposed scheme can improve the accuracy when the 
trustworthy service discovery process is based on public proximal MSNP participants’ 
rating scores. Recall that in our setting, each user in the Advogato dataset has ‘friends’ 
(people who have been rated as ‘Master’ level) and ‘non-friends’ (people who have been 
rated as ‘Apprentice’ or ‘Journeyer’ level). In this test case, we used the ‘non-friends’ as 
the proximal strangers of the requester. 

The test case compared the proposed scheme with the basic Naive scheme. The two 
schemes are summarised below: 

• Naive Scheme 

The requester computes a service provider’s trust score based on the average rat¬ 
ing values of all the requester’s ‘non-friends’ who have rated the service provider. 
The service provider is excluded from the list of ‘non-friends’. 

• Proposed Scheme 

The requester computes a service provider’s trust score based on a selected rec- 
ommender based on both credibility and experience computed from the ‘non¬ 
friends’ list. Same as the Naive scheme, the service provider is excluded from the 
list of ‘non-friends’. 

We also included two additional schemes—Experience Only (Exp Only) and Credi¬ 
bility Only (Credit Only)—in which the requester selects a recommender based on only 




experience and based on only credibility respectively. These two schemes were included 
because we wish to show that the proposed scheme (based on both credibility and expe¬ 
rience) provides better prediction accuracy than the cases of only using one of them to 
predict the reputation rating value. 

When referring to the ratings from the public, the average minimum transactions 
required were the same, because the requester had to collect all the proximal MSNP 
participants’ rating data in order to identify their credibility and experience. The value— 
7 is the average number of ‘non-friends’ that each user had in the Advogato dataset. 

In our test, we removed all the friends from the dataset. Each requester derived an¬ 
other user’s rating score based on other user’s rating values (i.e., public recommenda¬ 
tions). 


Scheme 

Comparable 

Count 

Prediction 

Accuracy 

Average Minimum 

Transaction Required 

Proposed Scheme 
using both Credibility 
and Experience 

851 

0.703078 

7 

Naive Scheme 

851 

0.504942 

7 

Experience Only 

Scheme 

851 

0.686321 

7 

Credibility Only 

Scheme 

851 

0.499681 

7 


Table 3. Comparison of Trust Schemes’ Accuracy and Transaction Costs of Public 
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Figure 14. Predictive Rating Accuracy Comparison of Different Schemes based on Public 

Table 3 shows the tabulated results, and Figure 14 the results in graphical form. 
Since the transaction cost of all schemes were the same, we did not need to calcu¬ 
late their cost-performance index value to compare their performance in this case. As 
the result shows, the accuracy of the Naive scheme was 50%, which means that if the 



requester computes a provider’s trust based on the average trust rating scores from all 
the proximal MSNP participants, it will only have a 50% chance for the result to match 
what the requester expects. If the requester computes the provider’s trust score based on 
the most experienced MSNP participant’s rating (Exp Only), there is a 69% chance that 
the result will match what the requester expects. On the other hand, if the requester only 
refers to the trust score of the highest credible MSNP participants (Credit Only), there is 
only a 50% chance that the result can match what the requester expects. Our proposed 
scheme which combines experience with credibility outperforms the other schemes with 
a 70% chance. Overall, all these schemes perform better than the Naive scheme in terms 
of accuracy. 

The proposed scheme is shown to improve the accuracy when the prediction is based 
on public proximal MSNP participants’ rating scores. However, since the rating score 
was computed based on strangers’ ratings, the scheme was unable to reduce the trans¬ 
action cost like the schemes based on friends and FOAF did. Because the requester did 
not have strangers’ ratings pre-stored in its local memory or its cloud storage, in order to 
identify and compare the experience of all the proximal MSNP participants, the requester 
had to collect all the rating data from all the proximal participants’ agents. Reducing the 
transaction cost in public-based trustworthy service discovery for MSNP requires further 
investigation. We consider this as one of our future research directions. 


8. Summary and Future Research Direction 

In this paper, we have presented the context-aware proactive service discovery scheme 
for service-oriented MSNP to reduce service discovery latency. Apart from service dis¬ 
covery in MSNP, trustworthiness has also been addressed. While existing work in trust 
management of MP2P environment focused on the trust model, and did not consider 
data transmission overhead issues, we have presented a lightweight trustworthy service 
discovery scheme specifically for service-oriented MSNP. 

Although the proposed schemes in this paper can enhance the overall service dis¬ 
covery performance, the dynamic nature of MSNP environment can still lead to unpre¬ 
dictable situations in which mobile devices cannot perform the service discovery effec¬ 
tively. For example, a service advertiser attempting to advertise its service by utilising 
push-based approach may suddenly run low on hardware resource availability due to the 
sudden increase in the number of MSNP participants joining the environment. Another 
example, during trustworthy service discovery, a requester may only have the option to 
refer to the reputation rating from public proximal recommenders in which the requester 
has to identify the credibility of each candidate recommender. If the number of candi¬ 
date recommenders is large, the overall process of determining trust can create serious 
latency. There is therefore a need to utilise the task offloading mechanism of mobile 
cloud computing dynamically at runtime when the mobile device is unable to handle an 
unexpected situation in service-oriented MSNP. 

We have identified several subjects for future research directions. 

Social-aware service discovery for MSNP —Our context-aware user preference associ¬ 
ated proactive service discovery for MSNP scheme requires a fair amount of con¬ 
text information associated service discovery and interaction records in order to 
predict the user preferred service type. However, for a user who has none or a few 



records, the scheme is unable to predict the user preferred service type regarding 
to the context information of the user’s current environment. One possible solution 
is to utilise the context associated service interaction records from the user’s social 
groups such as friends or friends of a friend based on some similarity measurement 
between the user and his/her friend’s profiles. However, a proactive service discov¬ 
ery scheme that relies on social-driven information will incur additional data re¬ 
trieval cost at runtime, which can increase the overall service discovery makespan. 
A proper solution to overcome such an issue requires further investigation. 

A lightweight trustworthy service discovery for public MSNP —The proposed scheme 
for lightweight trustworthy service discovery is applicable when the user has a fair 
amount of reputation rating data from friends or friend of a friend. If the reputation 
rating data comes from the public, it is inevitable that the requester has to retrieve 
all the available reputation rating data from the available proximal MSNP partic¬ 
ipants. The transaction cost can also be high when the environment consists of a 
large number of proximal MSNP participants. 
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